home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 599 < prev    next >
Text File  |  1996-08-06  |  34KB  |  791 lines
  1. Path: senator-bedfellow.mit.edu!faqserv
  2. From: mike@vlsivie.tuwien.ac.at
  3. Newsgroups: comp.unix.questions,comp.std.internat,comp.software.international,comp.lang.c,comp.windows.x,comp.std.c,comp.answers,news.answers
  4. Subject: Programming for Internationalization FAQ
  5. Supersedes: <internationalization/programming-faq_824542314@rtfm.mit.edu>
  6. Followup-To: comp.unix.questions,comp.std.internat,comp.software.international,comp.lang.c,comp.windows.x,comp.std.c
  7. Date: 19 Mar 1996 03:49:32 GMT
  8. Organization: TU Wien
  9. Approved: news-answers-request@MIT.EDU
  10. Expires: 2 May 1996 03:44:19 GMT
  11. Message-ID: <internationalization/programming-faq_827207059@rtfm.mit.edu>
  12. NNTP-Posting-Host: bloom-picayune.mit.edu
  13. Mime-Version: 1.0
  14. Content-Type: text/plain; charset=ISO-8859-1
  15. Content-Transfer-Encoding: 8bit
  16. Summary: This FAQ discusses writing programs which can handle
  17.          different language conventions/character sets/etc.
  18.          Applicable to all character set encodings; with particular 
  19.      emphasis on ISO-8859-1.
  20. X-Last-Updated: 1995/10/11
  21. Originator: faqserv@bloom-picayune.MIT.EDU
  22.  
  23.  
  24. Archive-name: internationalization/programming-faq
  25. Posting-Frequency: monthly
  26. Version: 1.91
  27.  
  28.  
  29.           Programming for Internationalization
  30.  
  31.               Michael K. Gschwind
  32.  
  33.  
  34.  
  35. DISCLAIMER: THE AUTHOR MAKES NO WARRANTY OF ANY KIND WITH REGARD TO
  36. THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
  37. OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
  38.  
  39. Note: Most of this was tested on a Sun 10, running SunOS 4.1.* - other
  40. systems might differ slightly
  41.  
  42. This FAQ discusses topics related to internationalization. Simple i18n
  43. support for Europe, Latin America, and the Middle East might use of
  44. the ISO 8859-X based 8 bit character sets.  For wider portability, a
  45. standard such as Unicode is in order.
  46.  
  47. This FAQ discusses how to program applications which support the use
  48. European (Latin American) national character sets on UNIX-based
  49. systems and standard C environments, and discusses some choices with
  50. respect to character sets.
  51.  
  52.  
  53. INTRODUCTION 
  54.  
  55. Most of the information given here is independent of the character
  56. encoding used (e.g. DEC MCS, ISO Latin-X, etc.), but can be applied to
  57. any character set, providing the programming environment has
  58. provisions for this standard.
  59.  
  60.  
  61. 1. Which coding should I use for accented characters?
  62. Use the internationally standardized ISO-8859-1 character set to type
  63. accented characters. This character set contains all characters
  64. necessary to type (West) European languages. This encoding is also the
  65. preferred encoding on the Internet.  ISO 8859-X character sets use the
  66. characters 0xa0 through 0xff to represent national characters, while
  67. the characters in the 0x20-0x7f range are those used in the US-ASCII
  68. (ISO 646) character set.  Thus, ASCII text is a proper subset of all
  69. ISO 8859-X character sets.  
  70.  
  71. The characters 0x80 through 0x9f are earmarked as extended control
  72. chracters, and are not used for encoding characters.  These characters
  73. are not currently used to specify anything.  A practical reason for
  74. this is interoperability with 7 bit devices (or when the 8th bit gets
  75. stripped by faulty software).  Devices would then interpret the character
  76. as some control character and put the device in an undefined state.
  77. (When the 8th bit gets stripped from the characters at 0xa0 to 0xff, a
  78. wrong character is represented, but this cannot change the state of a
  79. terminal or other device.)
  80.  
  81. This character set is also used by AmigaDOS, MS-Windows, VMS (DEC MCS
  82. is practically equivalent to ISO 8859-1) and (practically all) UNIX
  83. implementations.  MS-DOS normally uses a different character set and
  84. is not compatible with this character set. (It can, however, be
  85. translated to this format with various tools. See section 5.)
  86.  
  87. Footnote: Supposedly, IBM code page 819 is fully ISO 8859-1 compliant.
  88.  
  89.  
  90. ISO 8859-1 supports the following languages:
  91. Afrikaans, Basque, Catalan, Danish, Dutch, English, Faeroese, Finnish,
  92. French, Galician, German, Icelandic, Irish, Italian, Norwegian,
  93. Portuguese, Spanish and Swedish.
  94.  
  95. (It has been called to my attention that Albanian can be written with
  96. ISO 8859-1 also.  However, from a standards point of view, ISO 8859-2
  97. is the appropriate character set for Balkan countries.)
  98.  
  99. ISO 8859-1 is just one part of the ISO-8859 standard, which specifies
  100. several character sets:
  101. 8859-1    Europe, Latin America
  102. 8859-2  Eastern Europe
  103. 8859-3  SE Europe/miscellaneous (Esperanto, Maltese, etc.) 
  104. 8859-4  Scandinavia/Baltic (mostly covered by 8859-1 also)
  105. 8859-5  Cyrillic
  106. 8859-6  Arabic
  107. 8859-7  Greek 
  108. 8859-8  Hebrew
  109. 8859-9  Latin5, same as 8859-1 except for Turkish instead of Icelandic
  110. 8859-10 Latin6, for Lappish/Nordic/Eskimo languages
  111.  
  112. Another nascent standard is UNICODE (ISO 10646).  UNICODE is an
  113. extension of ISO 8859-1 (which itself is an extension of US-ASCII) to
  114. wide characters.  Thus, most of the world's languages (including
  115. Japanese, Korean, Chinese...) can be covered.
  116.  
  117. Unicode is advantageous because one character set suffices to encode
  118. all the world's languages.  The degree of Unicode support available
  119. depends on the operating system and on application availability. 
  120. However very few programs support wide characters. Thus, a `cheap'
  121. upgrade from 7 bit US-ASCII might be to only 8 bit wide character sets
  122. (such as the ISO 8859-X).  Unfortunately, some programmers still
  123. insist on using the `spare' eigth bit for clever tricks, which will
  124. make conversion more difficult.
  125.  
  126. Footnote: Some people have complained about missing characters,
  127.           e.g. French users about a missing 'oe'.  Note that oe is 
  128.           not a character, but a ligature (a combination of two
  129.           characters for typographical purposes).  Ligatures are not 
  130.           part of the ISO 8859-X standard.  (Although 'oe' used to 
  131.           be in the draft 8859-1 standard before it was unmasked as
  132.           `mere' ligature.)
  133.  
  134.  
  135.  
  136.  
  137. 2. Choosing the character set encoding
  138.  
  139. Depending on your needs, you will probably want to choose different
  140. solutions.  A quick shot i18n of US programs might simply be going to
  141. 8 bit and use one of the ISO 8859-X character sets.
  142.  
  143. If you have a choice and start from scratch, you might want to
  144. consider Unicode.  There are several aspects to choosing a particular
  145. character set (and you may want to decide on different character sets
  146. for different purposes):
  147. 1) what codeset should the application run in?  
  148. 2) what codeset should files be saved in 
  149. 3) what codeset is used as output (to screens etc.) and 
  150. 4) should wide characters or multi-byte characters be used (this
  151.    choice may be different for each of points 1-3)
  152.  
  153. For example, if portability of your files across cultural borders is
  154. an objective, you might want to use some form of Unicode encoding to
  155. achieve this.  If interaction with other tools in your environment is
  156. the main objective, and these tools use an encoding different from
  157. Unicode, this character set might be used instead.  
  158.  
  159. Using Unicode internally but writing a different format to files may
  160. sound funny (esp. if the output file format is only a subset of
  161. Unicode), but you would only have to adapt the file write and read
  162. functions and the same program will be able to execute in all
  163. countries your product might be used...)
  164.  
  165. Also, terminals and/or which process Unicode may not be available (or
  166. you might have to support legacy hardware), so you might need to adapt
  167. the output format to a third standard.
  168.  
  169.  
  170. 2. Getting your environment right for ISO 8859-X
  171. To configure your environment such that you can enter, process and
  172. display 8 bit ISO characters, check out the ISO-8859-1 FAQ available
  173. via anonymous ftp from ftp.vlsivie.tuwien.ac.at in
  174. /pub/8bit/FAQ-ISO-8859-1.  
  175.  
  176. If you use a different encoding, you will probably also have to
  177. configure your system to fully support that encoding.
  178.  
  179.  
  180.  
  181. 3. Setting your environment for ISO-C (ANSI-C) programs
  182. The ISO C Standard (ANSI C Standard 4.4) defines several functions for
  183. supporting localization. To set your international environment on
  184. program startup, you should make one or several calls to the setlocale
  185. functions.  Calls to this function will predetermine the reaction of
  186. other localization functions according to your language/country
  187. environment.
  188.  
  189. To configure a particular aspect of you environment, say the number
  190. representation, you would call
  191. --
  192. setlocale (LC_NUMERIC, "Germany");
  193. --
  194.  
  195. This call would set all number representation functions defined in the
  196. localization set to return numbers in the format used in Germany.  If
  197. the call was successful, setlocale will return the name of your
  198. locale.  A NULL return value indicates failure.  Note that the
  199. environments are predetermined outside your C program by the system
  200. you run on. (So the example given here is likely to fail on all but a
  201. few systems.) Check the setlocale manual page or your system
  202. documentation to find out about the environments available.
  203.  
  204. There are several LOCALE types available for different localization
  205. aspects (currency sign, number representation, characters sets). The
  206. value they can take is highly system dependent. Also, it should be up
  207. to the user to define the locale environment he needs. 
  208.  
  209. A C program inherits its locale environment variables when it starts up.
  210. This happens automatically.  However, these variables do not
  211. automatically control the locale used by the library functions, because
  212. ISO/ANSI C says that all programs start by default in the standard C
  213. locale.  To use the locales specified by the environment, The POSIX
  214. standard defines the following call:
  215. -----
  216. setlocale (LC_ALL, "");
  217. -----
  218.  
  219. Of course, you can only set part of your environment, by calling, say:
  220. ----
  221. setlocale (LC_CTYPE, "");
  222. ----
  223. This only defines the character classification macros (defined in
  224. ctype.h).
  225.  
  226. This is a list of local categories:
  227.  
  228.                    Effect of Specifying   Environment Variable
  229.      category      the Value              Affected
  230.      __________________________________________________________
  231.  
  232.      LC_ALL        Sets or queries        LANG
  233.                    entire environment
  234.      LC_COLLATE    Changes or queries     LC_COLLATE
  235.                    collation sequences
  236.      LC_CTYPE      Changes or queries     LC_CTYPE
  237.                    character classifi-
  238.                    cation
  239.      LC_NUMERIC    Changes or queries     LC_NUMERIC
  240.                    number format infor-
  241.                    mation
  242.      LC_TIME       Changes or queries     LC_TIME
  243.                    time conversion
  244.                    parameters
  245.      LC_MONETARY   Changes or queries     LC_MONETARY
  246.                    monetary information
  247.  
  248.  
  249.  
  250.  
  251. 4. Using the locale information for character classification
  252. If you write a program which supports international use, you should
  253. use the available standardized functions, as only these will be
  254. influenced by the setlocale call. Thus, if you want to convert a
  255. capital letter in c to a lower case letter in l, _don't_ write:
  256.  
  257. l = c - 'A' + 'a';
  258.  
  259. While this will work for characters in the US-ASCII character set, it
  260. will not work with many other character sets. The following,
  261. standard-conformant code will:
  262.  
  263. #include <ctype.h>
  264.  
  265. ....
  266.  
  267. l = tolower(c);
  268.  
  269. Also note that the second code may actually be faster than even the
  270. full "C" locale functionality (for most implementations), as it
  271. replaces a complex expression ( (c<='Z' && c>='A')? c-'A'+a:c; )by a simple
  272. table lookup!
  273.  
  274. Note that this ISO standard is independent of the character set
  275. encoding used!
  276.  
  277.  
  278.  
  279. 5. Language independent messages
  280. There are two competing standards for language independent messages:
  281. one by X/Open, and another one propagated by Sun.  The X/Open standard
  282. seems to have found a larger following as it has been around for a
  283. longer time.  As of Solaris 2.x, Sun supports both the X/Open and Sun
  284. message standards.  (they used to support only their own "standard".)
  285.  
  286. 5.1 X/Open language independent messages
  287. X/Open defines a method for providing language-independent messages.
  288. Error messages are kept in a catalog which is opened upon program
  289. start with a locale specification.  Then the message number and a set
  290. specification are used to index the message catalog.  A default fourth
  291. argument is specified which will be printed if a particular message
  292. cannot be found in the catalog. 
  293.  
  294. Here is the world-famous C program using the language-independent
  295. X/Open message standard:
  296. --------------------------------------------------------------------------
  297. #include <stdio.h>
  298. #include <nl_types.h>
  299.  
  300. #define SET 1
  301. #define MSG_HELLO 1
  302.  
  303. nl_catd catfd;
  304.  
  305. int main (int argc, char **argv) {
  306.         /* Open the message catalog. We use the basename of the program
  307.          * as the catalog name. Of course, several programs can also
  308.          * share a  common catalog.
  309.          */
  310.         catfd = catopen (basename (argv [0]), NL_CAT_LOCALE);
  311.         /* catgets returns message MSG_HELLO from set SET from the 
  312.          * message catalog catfd. If catfd does not refer to a message
  313.          * catalog, or the requested message cannot be found, the
  314.          * catalog, or the requested message cannot be found, the
  315.          * fourth argument is returned.
  316.          */
  317.         printf (catgets (catfd, SET, MSG_HELLO, "hello, world\n"));
  318.         catclose (catfd);
  319.         return 0;
  320. }
  321. -------------------------------------------------------------------------
  322.  
  323. For catopen, specify the constant NL_CAT_LOCALE to open the message
  324. catalog for the locale set for the LC_MESSAGES variable; using
  325. NL_CAT_LOCALE conforms to the XPG4 standard.  You can specify 0 (zero)
  326. for compatibility with XPG3; when oflag is set to zero, the locale set
  327. for the LANG variable determines the message catalog locale.
  328.  
  329. Several utilities exist for generating message catalogs and for
  330. upgrading programs which contain hard-wired strings:
  331. * gencat is used to generate message catalogs
  332. [All other programs are OS-specific:]
  333. * Ultrix and OSF support the extract program which will extract string
  334.   constants from the C source code, and has an option to replace these
  335.   strings with calls to catgets.
  336. * HP/UX has a similar utility called findmsg.
  337. * Under OSF, message catalogs may be listed with the dspcat utility.
  338. * HP/UX calls a similar utility dumpmsg.
  339.  
  340.  
  341. 5.2 Sun/Uniforum 
  342. Sun implements a different set of functions functions to support i18n
  343. of messages.  This mechanism is now also used by the GNU project to
  344. support localized error messages:
  345.  
  346. You can either use:
  347. -----------------------------------------------
  348.  
  349. main()
  350. {
  351.     // get the message catalog named "helloprogram" 
  352.     // for the hello world program
  353.     textdomain("helloprogram");    
  354.  
  355.     // get the translation for the "Hello, world\n" string
  356.     printf(gettext("Hello, world\n"));
  357. }
  358. -----------------------------------------------
  359.  
  360. or you can roll all in one and write
  361.  
  362. -----------------------------------------------
  363. main()
  364. {
  365.     // get the translation for the "Hello, world\n" string 
  366.     // from the message catalog "helloprogram"
  367.     printf(dgettext("helloprogram","Hello, world\n"));
  368. }
  369. -----------------------------------------------
  370.  
  371. The LC_MESSAGES locale category setting determines the locale of
  372. strings that gettext() returns.  The message catalogs are generated
  373. with either the installtxt or gencat commands.
  374.  
  375. No opening of files as in the old SYS V and X/Open routines, and no
  376. handling of message numbers that you must have in a database to
  377. administer.  However, this mechanism is only supported by Sun.  Sun
  378. tried to push it into COSE, but without success. 
  379.  
  380. This mechanism is available eithe with the Xview environment (the
  381. source is available with the XView code), or from the GNU project at
  382. ftp://prep.ai.mit.edu/pub/gnu/gettext-0.7.tar.gz. 
  383.  
  384.  
  385.  
  386. 5.3 POSIX language independent messages
  387. Neither of the previous two mechanisms is in the POSIX standard.
  388. There was much disagreement in the POSIX.1 committee about using the
  389. gettext routines vs. catgets (XPG).  In the end the committee couldn't
  390. agree on anything, so no messaging system was included as part of the
  391. standard. I believe the informative annex of the standard includes the
  392. XPG3 messaging interfaces, "...as an example of a messaging system
  393. that has been implemented..."
  394.  
  395. They were very careful not to say anywhere that you should use one set
  396. of interfaces over the other.
  397.  
  398.  
  399.  
  400. 6. Other localization aspects in ISO/ANSI C (and POSIX environments)
  401. For a more thorough discussion of localization and
  402. internationalization (aka. i18n), check your system vendors
  403. documentation, and the C library manual which comes with the FSF's
  404. glibc library (Chapter 19, 'Locales and Internationalization').
  405.  
  406.  
  407.  
  408. 7. Internationalization under X11
  409. While X11 is farther than most system software when it comes to
  410. internationalization, it still contains many bugs.  A number of bug
  411. fixes can be found at URL http://www.dtek.chalmers.se:80/~maf/i18n/.
  412.  
  413. 7.1 Output
  414. To output text encoded with ISO 8859-1 under X11, simply invoke the X
  415. display routines with 8 bit characters as you would use them with
  416. 7-bit ASCII.  You should however choose a font which contains bitmaps
  417. for these characters.  You can use the xfd utility to display a font
  418. to verify that it contains a full set of characters.
  419.  
  420.  
  421. 7.2 Input
  422. If you use a national keyboard (that is a keyboard, which has distinct
  423. keys for your countries special characters), inputting accents is
  424. straight forward and you'll get the corresponding characters by using
  425. the X11 input functions.
  426.  
  427. Sometimes it may be necessary to input characters for which there are
  428. no keys on your keyboard (e.g. if you want to enter the German '▀'
  429. from a French keyboard).  
  430.  
  431.  
  432. "X11R5 and X11R6 both have extensive support for i18n, but due to a
  433. variety of factors the R5 i18n was not well understood or widely
  434. used.  Many people resorted to a work-around and might have been
  435. disappointed when R6 did not include this feature.  It is important
  436. to recognize that the correct use of R5 and R6 i18n features will
  437. ensure maximum portability of your program." [X Consortium's view]
  438.  
  439. Unfortunately, not even the xterm terminal emulator supplied with the
  440. X11 distribution by the X Consortium supports this input method
  441. mechanism.  The lack of missing code samples (and support for this
  442. feature in some non-essential, but widely used X11 parts) may have
  443. contributed to this situation.
  444.  
  445.  
  446. Footnote: Amongst other reasons, the X Consortium decision not to add
  447. support for input methods to the Xaw Athena widget contributes to this
  448. situation.  Xaw is officially not supported by the X Consortium, and
  449. thus has only marginally been improved since X11R4.  However, many
  450. users (and much of the PD software) live in an Xaw-only world, so they
  451. will not be able to benefit from this i18n effort.
  452.  
  453. X11 R5 and R6 support input methods for entering non-ASCII, and
  454. displaying and configuring text, menus etc. for a wide variety of
  455. languages.  This input method has to be installed by the application
  456. by calls to the Xlib library (or an Xt toolkit call).
  457.  
  458. [Under X11R5, some X servers (notably the Xsun server) will let you
  459. enter ISO characters by supplying a built-in escape mechanism, if no
  460. keys for these characters are on your keyboard, and will pass along
  461. and display ISO 8859-1.  This hack obviated the need to install an
  462. input method, but was less flexible.]  
  463.  
  464.  
  465. If you are using a toolkit, it is quite simple to support localization
  466. of your X11 code: 
  467. If you're using a toolkit -- Xt and a widget set like Motif or R6 Xaw --
  468. you need only add a single line of code to your source. Before any other 
  469. calls to Xt, add a call to XtSetLanguageProc, e.g.:
  470.  
  471.     int main (int argc, char** argv)
  472.     {
  473.         ...
  474.         XtSetLanguageProc (NULL, NULL, NULL);
  475.         top = XtAppInitialize ( ... );
  476.         ...
  477.     }
  478.  
  479. The LANG and LC_xxx environment variables (see section 3) will then be
  480. used to determine the 'input method' for this X application.  This
  481. input method is responsible for managing COMPOSE character sequences
  482. or any other input mechanism for this particular implementation.  Also
  483. see section 9 of ftp://ftp.vlsivie.tuwien.ac.at/pub/8bit/FAQ-ISO-8859-1,
  484. the FAQ on ISO 8859-1 usage.
  485.  
  486.  
  487. 7.3 Toolkits, Widgets, and I18N
  488. The preferred way of inputing national characters when a national
  489. keyboard is not available is one/several input methods.  These input
  490. methods will then support various kinds of compose sequences to enter
  491. national characters.
  492.  
  493. The environment variables LANG and/or LC_xxx select the language for
  494. the Input Method (IM), but if several input methods exist, the
  495. environment variable XMODIFIERS can be used to select a specific input
  496. method.
  497.  
  498. Xlib, Xt and (partially) Xaw support IMs.  Thus, applications written
  499. with Xlib or Xt can support IMs (see section 7.2 on how to install
  500. input methods under Xt).
  501.  
  502. Motif 1.2  or greater automatically uses the R5/R6 input method APIs.
  503. Thus applications using Motif 1.2+ can be made to support IMs.
  504. Several Motif 1.[01] versions also had similar functionality added to
  505. them by the respective vendors, but these extensions are
  506. vendor-specific and not portable.
  507.  
  508. Xaw i18n is based upon X11R5 i18n, not on R6.  Thus, it supports R5
  509. input methods.  R6 added OUTPUT METHODS which are good for mainly
  510. R-to-L languages, and a few new INPUT METHODS (in-the-spot and I think
  511. one other) that Xaw might not support.  Xaw does support
  512. over-the-spot, off-the-spot, and root-window conversion.  To make this
  513. work, you might need to set "*international: True" in your resources.
  514.  
  515.  
  516. FOOTNOTE: If you can have comments/corrections for this section and on
  517.           OpenLook, please let me know.
  518.  
  519.  
  520. 7.4 I18N under X11R6, General Information
  521. Background information from the X11R6 announcement:
  522. Internationalization (also known as I18N, there being 18 letters between the
  523. i and n) of the X Window System, which was originally introduced in Release
  524. 5, has been significantly improved in R6.  The R6 I18N architecture follows
  525. that in R5, being based on the locale model used in ANSI C and POSIX, with
  526. most of the I18N capability provided by Xlib.  R5 introduced a fundamental
  527. framework for internationalized input and output.  It could enable basic
  528. localization for left-to-right, non-context sensitive, 8-bit or multi-byte
  529. codeset languages and cultural conventions.  However, it did not deal with
  530. all possible languages and cultural conventions.  R6 also does not cover all
  531. possible languages and cultural conventions, but R6 contains substantial new
  532. Xlib interfaces to support I18N enhancements, in order to enable additional
  533. language support and more practical localization.
  534.  
  535. The additional support is mainly in the area of text display.  In order to
  536. support multi-byte encodings, the concept of a FontSet was introduced in R5.
  537. In R6, Xlib enhances this concept to a more generalized notion of output
  538. methods and output contexts.  Just as input methods and input contexts sup-
  539. port complex text input, output methods and output contexts support complex
  540. and more intelligent text display, dealing not only with multiple fonts but
  541. also with context dependencies.  The result is a general framework to enable
  542. bi-directional text and context sensitive text display.
  543.  
  544. The description of the X11R6 internationalization framework is
  545. available via anonymous ftp from ftp.x.org in
  546. /pub/R6untarred/xc/doc/specs/i18n.
  547.  
  548.  
  549.  
  550. 8. Supporting I18N Network Protocols
  551. 8.1 MIME
  552. MIME is specified in RFC 1521 and RFC 1522 which are available from
  553. ftp.uu.net.  There is also a MIME FAQ which is available via anonymous
  554. ftp from ftp.ics.uci.edu in /mh/contrib/multimedia/mime-faq.txt.gz.
  555. (This file is in compressed format. You will need the GNU gunzip
  556. program to decompress this file.)
  557.  
  558. If you want to write applications which support the MIME protocol,
  559. there are several libraries/tools which can ease your task:
  560.  
  561.  
  562. 8.1.1 metamail
  563. Source for supporting MIME (the `metamail' package) in various mail
  564. readers is available via anonymous ftp from thumper.bellcore.com in
  565. /pub/nsb.  This distribution consists of several utilities, which can
  566. be called by MIME applications to handle MIME types.
  567.  
  568.  
  569. 8.1.2 MIMElt
  570. A "lightweight" MIME library available via anon ftp from
  571. oslonett.no:Software/MsDos/Comm/Offline/mimeltXX.zip 
  572.  
  573. It is source code (ANSI C) packaged as a library to facilitate
  574. construction of a limited MIME facility (limited == handling only
  575. character-set aspects of MIME, not the multimedia-aspects).  It
  576. includes hooks to recode character sets into whatever system you are
  577. running off (e.g.  if you read mail on a MsDos platform using CP-850,
  578. MIMElite may be set up so that QUOTED-PRINTABLE ISO Latin 1 is recoded
  579. into CP-850 for reading and saving to file).
  580.  
  581. It's main use is to provide programmers of so-called "off-line 
  582. readers" (used by users who access Internet mail through dial-up 
  583. service providers) with the tools needed to include proper support for 
  584. QUOTED-PRINTABLE encoding in their product.
  585.  
  586. The archive also contains a couple of sample applications that 
  587. demonstrates how the library may be used.  UNMIME is a stand-alone 
  588. utility to decode MIME-encoded messages (e.g. it works like UUDECODE
  589. for binary files with BASE64 encoding), SENDMIME is a simple utility
  590. to send MIME-encoded messages if your service provider doesn't have
  591. PINE or similar tools.
  592.  
  593. The current version (2.1) is limited to character set issues.  I am
  594. about to release version 2.2, which will support additional 
  595. Content-Types (e.g. "application/octet-stream").
  596.  
  597.  
  598.  
  599. 9. Programming in Prolog 
  600. Quintus Prolog and SICStus Prolog accepts ISO characters as part of
  601. atoms, so you can even define goal names containing accented
  602. characters.  I/O of 8 bit characters is (obviously) also supported.
  603.  
  604. Quintus Prolog also can handle Kanji.
  605.  
  606.  
  607. 10. Unicode
  608.  
  609. Support for wide characters has been incorporated in a number of new
  610. operating system offerings, including SVR4 compliat systems (e.g.,
  611. Solaris 2.x, Unixware, IRIX5/6, Sony NEWSOS 6.x).  Other systems which
  612. support wide characters are Digital Unix (nee OSF/1), DEC Ultrix
  613. (version 4.x), SunOS (as of version 4.1.x), HPUX 9 and 10, AIX 3 and
  614. 4, several public BSD versions (FreeBSD, NetBSD, BSD/OS) as well as
  615. Linux, although the Linux locale support is weak.
  616.  
  617. Note that 'support for Unicode' means different things to different
  618. people.  Thus, Unix vendors claim Unicode support if they fulfill the
  619. following:
  620. * They define wchar_t in stddef.h. 
  621. * They have ANSI functions mblen, mbstowcs, wctomb, mbtowc, and wcstombs. 
  622. * The remaining infrastructure (file names, program names, shells,
  623.   systems programs, etc.) is still at 8 bit characters.
  624.  
  625. Note that support for wchar_t and the mentioned ANSI functions is
  626. enopugh to write Unicode programs.  You can even use Unicode
  627. characters in falinames, if you use an 8 bit file-system safe
  628. transformation for Unicode.
  629.  
  630. Footnote: Transformations are Unicode magic: in order to comply with
  631.           exisitng infrastructure, Unicode can be 'transformed' into a
  632.           variety of encodings: 8 bit, 16 bit, file system safe, etc.etc. 
  633.           When needed, these transformations are then transformed back
  634.           into a canonical Unicode form.
  635.  
  636. However, you may not be able to process these filenames properly from
  637. within your other favorite programs, and they might not even display
  638. correctly, depending on you output devices.  Thus, even simple
  639. operations such as 'mv', 'cp' or file redirection may be problematic!
  640.  
  641. Wide character strings have no locale info associated with them so would 
  642. be meaningless in the wrong locale. You never write files of wchar_t, you 
  643. always convert the data to multi-byte format. The same rationale would 
  644. apply to filenames in the file system, exec parameters, shells, etc. 
  645. Since the API for doing these thing all use char or char* it would be
  646. very difficult to get wchar_t data to be used. 
  647.  
  648. The only OS I know of that uses Unicode is MS WindowsNT and this is one 
  649. of the difficulties in exporting NTFS file systems to Unix. The APIs for
  650. things like (f)open, etc., are all ANSI, so the library or the kernel
  651. must convert the ASCII string into a Unicode wchar_t string. (NT doesn't
  652. have the exec* family of functions, it uses spawn*, which all take
  653. char or char* arguments.)  All system calls under NT have ASCII and
  654. Unicode variations.  Internally, the ASCII versions seem to translate
  655. to Unicode, but this is just a guess.
  656.  
  657. I'm not aware of any Unix that has support for ISO-10646 (or Unicode) yet.
  658. X has preliminary support for it in R6, but it only supports CJK and
  659. ASCII at this point in time and it would be difficult, if not impossible
  660. to use given that there is no underlying OS support for it.
  661.  
  662. ACK: Thanks to Kaleb Keithley who explained these concepts to me. 
  663.      All errors are mine.
  664.  
  665.  
  666. 11. ISO 8859-1 on non-UNIX systems
  667. 11.1 MS-DOS
  668. MS-DOS generally uses its own characters set. There are several code
  669. pages (one with the same symbols as ISO 8859-1, albeit at different
  670. character code positions, which can lead to problems with the transfer
  671. of data).
  672.  
  673. If interoperability without data conversion is your goal, you can
  674. reconfigure your MS-DOS PC to use an ISO-8859-1 code page. Check out
  675. the anonymous ftp archive ftp.uni-erlangen.de, which contains data on
  676. how to do this (and other ISO-related stuff) in /pub/doc/ISO/charsets.
  677. The README file contains an index of the files you need.
  678.  
  679. Most (all?) C compilers/libraries for MS-DOS have only minimal support
  680. for the ANSI/POSIX locale mechanism.  The setlocale() and localeconv()
  681. calls (and stuff like strxfrm()) are generally hardwired.
  682.  
  683.  
  684. 11.2 MS Windows
  685. MS-Windows (using code page 1252) normally uses the first 256
  686. characters of Unicode, which is (for all practical purposes)
  687. equivalent to ISO 8859-1.  Thus, data representation and conversion
  688. for interoperability with other ISO 8859-1 compliant systems is not an
  689. issue.  
  690.  
  691. It seems that C libraries for MS Windows do not support the ANSI/POSIX
  692. locale mechanism. (If you have any experiences with that, please let
  693. me know.)  There is a POSIX-like mechanism in some Microsoft platform
  694. services, but none in the compilers from any vendor.
  695.  
  696. Windows NT supports Unicode, which is a super-set of ISO 8859-1.
  697. There does not seem to be support for the locale mechanism under
  698. Windows NT.
  699.  
  700.  
  701. 11.3 OS/2
  702. Text mode OS/2 programs generally suffer the same limitations as do
  703. MS-DOS programs, because the display hardware is the same.
  704.  
  705. Presentation Manager OS/2 programs using code page 1004 will order
  706. the font glyphs in the same sequence as ISO 8859-1 (although of
  707. course whether the glyphs will actually look anything like those
  708. from ISO 8859-1 depends entirely from the font).
  709.  
  710. The IBM CSet++ compiler supports full internationalization, with
  711. several predefined locales.
  712.  
  713. The Borland C++ compiler supports only the "C" locale.
  714.  
  715. The Watcom C++ compiler supports only the "C" locale.
  716.  
  717. The Metaware High C++ compiler supports only the "C" locale.  It
  718. does, however, also support UNICODE, providing UNICODE character
  719. types and UNICODE versions of the appropriate parts of the standard
  720. library (including I/O).
  721.  
  722.  
  723.  
  724. 11.4 Apple Macintosh
  725. MacIntoshes have their own non-standard character encodings; the first
  726. 128 characters are US-ASCII but the remaining characters are
  727. non-standard.  If you connect to the rest of the world, NCSA telnet
  728. does support ISO 8859-1.
  729.  
  730. Symantec's THINK C provides setlocale() is provided for ANSI C
  731. compatibility only.  Only the minimal "C" locale is implemented.
  732. It doesn't change your program's locale.
  733.  
  734. I do not know whether C libraries (for which compilers?) for the
  735. MacIntosh support the ANSI/POSIX locale mechanism. If you have any
  736. experiences with that, please let me know.
  737.  
  738. In fact the Macintosh has very good i18n facilities, but they are
  739. accessed through non-ANSI-standard things like the Script Manager, so
  740. they are useless for people who want to write portable programs.
  741.  
  742.  
  743. 11.5 DEC OpenVMS (Alpha and Vax systems)
  744. DEC recently implemented support for the XPG4 world-wide portability
  745. interfaces as well as XPG4 message catalogs. You need DEC C V5.0 and
  746. OpenVMS V6.2 (for either Alpha or VAX systems)
  747.  
  748.  
  749. 11.6 Amiga
  750. The AmigaOS uses ISO-8859-1. As of OS version 2.1, Amiga-specific
  751. means of localization are available.
  752.  
  753.  
  754.  
  755. 12. Home location of this document
  756. 12.1 www
  757. You can find this and other i18n documents under URL
  758. http://www.vlsivie.tuwien.ac.at/mike/i18n.html.
  759.  
  760. 12.2 ftp
  761. The most recent version of this document is available via anonymous
  762. ftp from ftp.vlsivie.tuwien.ac.at under the file name
  763. /pub/8bit/i18n-programming.  
  764.  
  765.  
  766. -----------------
  767.  
  768. Copyright ⌐ 1994,1995 Michael Gschwind (mike@vlsivie.tuwien.ac.at)
  769.  
  770. This document may be copied for non-commercial purposes, provided this
  771. copyright notice appears.  Publication in any other form requires the
  772. author's consent. (Distribution or publication with a product requires
  773. the author's consent, as does publication in any book, journal or
  774. other work.)
  775.  
  776. Dieses Dokument darf unter Angabe dieser urheberrechtlichen
  777. Bestimmungen zum Zwecke der nicht-kommerziellen Nutzung beliebig
  778. vervielfΣltigt werden.  Die Publikation in jeglicher anderer Form
  779. erfordert die Zustimmung des Autors.  (Verteilung oder Publikation mit
  780. einem Produkt erfordert die Zustimmung des Autors, wie auch die
  781. Ver÷ffentlichung in Bⁿchern, Zeitschriften, oder anderen Werken.)
  782.  
  783.  
  784. Michael Gschwind, Institut f. Technische Informatik, TU Wien
  785. snail: Treitlstrasse 3-182-2 || A-1040 Wien || Austria
  786. email: mike@vlsivie.tuwien.ac.at   PGP key available via www (or email)
  787. www  : URL:http://www.vlsivie.tuwien.ac.at/mike/mike.html
  788. phone: +(43)(1)58801 8156       fax: +(43)(1)586 9697
  789. Multiculturalism is the concept that European cultures should be
  790. flexible enough to accommodate the inflexibility of all others.
  791.